A remote access server program ("RAS") running on a server computer provides logical dial-in ports to remote computers. A remote computer accesses the RAS program via a remote modem connected to the remote computer. The remote modem transmits data through a telecommunications line to a server modem connected to the server computer. The server computer manages a pool of server modems that receive data from the telecommunications line and transmit that data to the server computer and that receive data from the server computer and transmit the data through the telecommunications line. Each modem in the pool of server modems exchanges data with the server computer through a physical port on the server computer. The RAS running on the server computer allows the remote computers access to the resources of a local area network to which the server computer is connected. Using this access to the local area network, users employing the remote computers can exchange data with computers attached to the local area network and use resources shared with the computers attached to the local area network.
A Sparta-Com asynchronous port sharing program ("SAPS"), also running on the server computer, is able to share logical ports with RAS and provide the shared logical ports to computers attached to the local area network, called networked computers, for data transmission. The SAPS provides users running on networked computers with the ability to dial out over a telecommunications line to remote computers as if each of the networked computers was directly connected to a modem. The SAPS can provide these server modems to a larger number of networked computers than the number of modems, or ports, available on the server computer, assuming that not all the networked computers need access to a server modem at the same time.
FIG. 1 displays a schematic diagram of data transfer facilitated by RAS and SAPS. In FIG. 1, five networked personal computers ("PCs") 101-105 are connected through a local area network 106 to a server computer 107. Five different users, user 1-user 5, are using the five networked personal computers. The server computer includes both a RAS 108 and a SAPS 109. The server computer is connected to three modems 110-112 (i.e., a modem pool) which are, in turn, connected to a telephone line 113. Each networked PC in FIG. 1 is connected through a separate logical network connection to the RAS and to the SAPS. For example, user 1 101 is connected to the RAS 108 through network connection 114 and is connected to the SAPS 109 through network connection 115. It appears to each networked computer, or user, in FIG. 1 that that computer has a dedicated, unshared physical port connection to a modem for outgoing data transfer. The SAPS running on the server computer provides this appearance of a dedicated physical port for outgoing calls to each of the networked PCs. In fact, the networked PCs are all sharing the small number of modems managed by the server computer. User 1, for example, might transfer data to three different remote computers through calls connected through modems 110, 111, and 112 in succession. From user 1's standpoint, however, it appears that all three calls were transmitted through a single modem connected to the logical port provided by the SAPS.
Systems of networked computers that share a pool of modems through the RAS and SAPS intermediaries, such as the system shown in FIG. 1, are managed and maintained by system administrators. The system administrator monitors the usage of the modems to detect overload conditions that require additional modems to be added to the system and to detect failed modems that are not processing incoming and outgoing data transfers at an acceptable level. In order to detect such problems the system administrator uses automated and manual tools for processing and examining a timeline of modem-related events.
FIG. 2 displays an example timeline of events for a server computer including a RAS and a SAPS. The vertical axis of FIG. 2 is a timeline 201. This example timeline extends from 11:56 p.m. on Sep. 17, 1997 through midnight to 12:05 a.m. on Sep. 18, 1997. Various events 202-219 are recorded along the timeline, including RAS-generated events, SAPS-generated events, and operating system events. For example, event 202 that occurs at 11:56:32 p.m. represents user 8 hanging up, or disconnecting, an incoming call. Event 203 that occurs at 11:56:48 p.m. represents user 1 initiating an outgoing telephone call. The data contained in this example timeline of FIG. 2 will be used throughout the following discussion and examples.
A system administrator typically does not have the capacity to manually record the series of events that occur in various time intervals within the server computer. The example of FIG. 2, for instance, shows a time interval of merely nine minutes for the small system of FIG. 1. The system administrator would normally require monitoring over days or weeks in order to collect sufficient data to make many of the determinations that are required for adequately managing and maintaining the system. System tools are provided by operating system vendors like, for example, the Windows NT Event Viewer. These tools identify and record network and operating system events over a selected time interval. Various filtering mechanisms are provided by these tools in order to capture some subset of the total number of different types of events that might occur.
FIG. 3 displays an example output from an Event Viewer for the events recorded from the timeline of FIG. 2. The Event Viewer displays, for each event, the date 301, time 302, the component that produced the event 303, a general category for the event 304, a number representing the specific event 305, a designation for the user associated with the event 306, and the device number of the device associated with the event 307. The Event Viewer displays additional information, including the number of bytes transferred during the event and an indication of the computer on which the event occurred. These additional data are contained in additional columns of the Event Viewer output, starting with column 308, but not shown in FIG. 3. The Event Viewer output of FIG. 3 essentially represents the data contained in FIG. 2 in table form. For example, event 203 in FIG. 2 corresponds to entry 309 in FIG. 3. The value for the event column in entry 309, "16," represents the making of an outgoing call. That call extends in time to entry 310, where the value in the event column, "32," represents user 1 disconnecting the outgoing call. The Event Viewer assigns various other numerical values to the different possible normal and error conditions that arise during the course of the system operation. For example, event 206 in FIG. 2 represents a user's unsuccessful attempt to make a connection using an incorrect password. That event is represented in FIG. 3 by entry 311, where the value in the event column, "8192," represents an incorrect password error. The device numbers in column 307 for all entries having a value in the source column equal to `RAS` or `SAPS` represent the number of the modem associated with the event, of which there are three, as shown in FIG. 1.
Although useful, the Event Viewer output does not represent an easy-to-use medium for system administration purposes. A system administrator desires various generalized reports of modem usage and the amount of logical port usage by various users, among other things. Extracting that information from the Event Viewer involves tedious manual data extraction and hand calculations. The example timeline of FIG. 2 and Event Viewer display of FIG. 3 are for a very small system, displayed in FIG. 1, over a very short interval of time. In actuality, a network system may have tens to hundreds of networked computers sharing a modem pool of many tens of modems. The system administrator needs to display usage information generated from Event Viewer monitoring that spans many hours or even days. The Event Viewer output over such time intervals might well comprise many hundreds of pages, from which the system administrator would have to spend days to extract and compile the information needed for maintenance and management of a network system.
As an aid to the system administrator, a RAS output generator has been developed. This RAS output generator collects data stored within an Event Viewer and compiles certain of the data into an Incoming Port Usage Report. FIG. 4 displays an example Incoming Port Usage Report for the data contained in FIG. 3. The Incoming Port Usage Report displays an entry for each completed data transfer through the RAS software component of the server computer. Each entry includes an identification of the user which made the incoming call 401, an indication of the modem through which the data was received by the system 402, the time at which the incoming call was received and the time at which the incoming call was completed 403 and 404, the total elapsed time of the call 405, and the number of bytes transferred during the call 406. Assuming that the number of bytes transferred is stored and made available in the additional columns not shown in FIG. 3 of the Event Viewer display, the Incoming Port Usage Report can be generated from the Event Viewer output in a single pass through the entries of the Event Viewer output.
Although more useful than the unprocessed Event Viewer output, the RAS output generator does not provide sufficient information for effective system administration of a system such as that shown in FIG. 1. A system administrator generally wants to collect and compile data about outgoing calls through the SAPS component of the server in addition to incoming calls managed by the RAS component of the server. However, the RAS output generator only collects and compiles information for incoming calls. Furthermore, the system administrator would like to be able to generate reports both from data stored within the Event Viewer, as well as from data archived in data files by previous instantiations of the Event Viewer. The RAS output generator can only collect data stored within the Event Viewer and cannot process files containing archived Event Viewer data. Finally, a system administrator would like to compile a variety of different reports depending on the types of problems and characteristics of the network that the system administrator is seeking to identify. The RAS output generator provides only the static Incoming Port Usage Report as shown in FIG. 4. It does not provide additional static reports, nor does it provide to the system administrator the ability to define and generate reports tailored to the system administrator's particular needs.